Search Results: "Cyril Brulebois"

17 June 2011

Cyril Brulebois: mesa: a disturbance in the Force!

Things aren t exactly going as smoothly as expected. Here are some explanations. First collateral damage: non-free fglrx and nvidia drivers. We have to admit we didn t think of those when we moved libGL.so.1 (and friends) from /usr/lib to /usr/lib/<triplet> (that s the move we call adding multiarch support ). In the mesa 7.10.3-2 upload, some Breaks statements were added to prevent users from installing new mesa packages if they still have old (without multiarch support) fglrx or nvidia packages. Solution: Sticking to the mesa packages in testing is the way to go until fixed fglrx and nvidia packages are uploaded. Second collateral damage: xserver-xorg-core in testing. The plan was to rebuild the server in unstable against the new mesa libraries, so that it would look into the new /usr/lib/<triplet> directory for mesa drivers. Since no source changes were needed, we went for a binNMU as explained in the previous blog post. That s the usual way to deal with libraries, and does the job very nicely. But that failed in this special case, for the following reasons:
  1. The server only has libgl1-mesa-dri in Recommends, so there s no hard dependency here.
  2. Usually, rebuilding a package against a new library means getting a dependency on the new library (typically because the binary compatibility has been broken, so the SONAME got bumped, meaning one depends on libfoo42 instead of libfoo41). And that means going in testing at the same time as the new library.
But in this case, rebuilding against the new library just means having a different search path somewhere in libglx.so. So the rebuilt package (2:1.10.2-1+b1) happily reached testing, which still contains the old mesa packages, which ship their files in the old /usr/lib path! Solution: Stick to 2:1.10.2-1 packages (snapshot.debian.org to the rescue), or wait a bit and get fixed packages. To get fixed packages, two things were needed:
  1. Getting the server package fixed in unstable: that means adding Breaks against old (pre-multiarch) mesa packages, as seen in 2:1.10.2-2. This will ensure that new server package built against new mesa will not be co-installable with old mesa packages, and both mesa and the server should migrate together to testing.
  2. Getting the server built again within testing, so that it gets built against old mesa, so that both mesa and the server in testing remains without multiarch until the packages in unstable are ready to migrate together.
While taking care of that second step, it was discovered that many buildds are still lacking a testing chroot, so there might be some delay until the server is rebuilt in testing (as 2:1.10.2-1+wheezy1). Eager users can use the time travel machine mentioned above to get stuff working again sooner. (As far as I can tell, the last problematic combination which would remain would be 2:1.10.2-1+wheezy1 server with new mesa, but we ll make sure we update the Breaks in the new mesa to make sure that it can t happen. Since it s not as urgent as getting the server in testing fixed, it s only queued for mesa 7.10.3-3 for now.)

14 June 2011

Cyril Brulebois: mesa: a disturbance in the Force?

Just a quick heads-up: I ve just uploaded mesa 7.10.2-4, which is multiarch-enabled, thanks to Steve Langasek. As explained in its changelog, this breaks the X server currently in testing and in unstable, but a rebuild is already pending, which will make everyone upgradable. For curious people, those commands took care of scheduling the binNMU, with a proper dep-wait:
wb nmu xorg-server . ALL . -m 'Rebuild against new (multiarch-enabled) mesa.'
wb dw xorg-server . ALL . -m 'libgl1-mesa-dev (>= 7.10.2-4)'
In the meanwhile, if your mirror gets a new mesa without the rebuilt server, your package manager should bail out and refuse to upgrade mesa (or propose to remove the server). So wait a bit, upgrade everything, and enjoy! mesa 7.10.3 (released a few hours ago) should reach unstable tomorrow, so that we can ask our users to track (possible) regressions between 7.10.2-3 and 7.10.3-1 to either 7.10.2-4 (multiarchification), or to 7.10.3-1 (the stable upgrade), thanks to the excellent http://snapshot.debian.org/ service.

30 May 2011

Cyril Brulebois: Domain name update

Almost 4 years ago, I decided to set up a tiny website, mostly for blogging purposes. Given I was using ikiwiki and my nickname s KiBi, ikibiki.org sounded fun, so I picked that one. Now, it s a bit long to type, error-prone (how many times did I type ikiwiki instead ), and even my family has troubles remembering it. Other kibi.* domain names weren t released in the meanwhile, so looking into stuff I care about, something cat-related could do the job. And since I ve been using mraw in my signature for a while, I picked that one. So my blog lives at http://blog.mraw.org/ now. The old domain name will be kept for a while though.

24 May 2011

Cyril Brulebois: Git tip of the day: insteadOf

The recent Alioth migration (thanks, Alioth folks!) led to slight variations in the URL schemes for various VCS. I guess some migration path will be considered but in the meanwhile that seemed to be a good example for the nice git-config insteadOf trick. Here s the bottom of ~/.gitconfig:
[url "git://anonscm.debian.org"]
    insteadOf = "git://git.debian.org"
[url "ssh://git.debian.org"]
    pushInsteadOf = "git://git.debian.org"
And tada! debcheckout picks the appropriate service (anonscm for anonymous access), and one is still able to push (through ssh) without having to change the URL in each and every .git/config file (which would also lead to higher CPU usage when updating afterwards).

4 May 2011

Cyril Brulebois: First source-only upload

A few hours ago I performed my first source-only upload, and that wasn t to a well-known Debian derivative. :) Thanks to Peter Hutterer for the initial idea I could handle that release, and to Alan Coopersmith for the handholding session.

11 April 2011

Cyril Brulebois: Debian XSF News #10

This is the tenth Debian XSF News issue. It is basically meant to be a follow-up to DXN#9.
  1. I completed the addition of the Sinhala language, and also dealt with big changes on the xkb-data (a.k.a. xkeyboard-config) side, as explained by Sergey Udaltsov. Protocol:
    • [KiBi] x11proto-core: the upload to experimental was a bit overcautious, so upload again unstable.
    Data: Library:
    • [KiBi] libx11: new upstream release, adding support for Sinhala unstable.
  2. The Graphical Installer started receiving improved portability. There were a few patches floating around adding udebs for generic drivers for non-Linux architectures. I cleaned them up a bit (especially on the vesa side, getting rid of libdrm entirely), got them test-built on a kfreebsd-amd64 box, while Samuel Thibault was doing the same on a hurd-i386 box. I raised the topic on debian-boot@, debian-bsd@, and debian-hurd@, mentioning the remaining steps. Drivers (all accepted by ftpmasters after a tiny trip to the NEW queue):
  3. Here are some other packages which got updated. Applications: Library:
    • [Chris,Julien,KiBi] mesa 7.10.1: long-awaited upload, finally checked, built, and uploaded experimental.
  4. Finally, let s mention migration to testing (from now on I ll use testing instead of wheezy so that it s clear it s about week after week migrations to the testing distribution, rather than our final plans for the next stable release). After a while, and thanks to some hand-holding from our nice release managers (hi, Adam!), linux-2.6, libdrm, mesa, xorg-server, and several dozen drivers migrated to testing. Yay!
  5. As a consequence, some other packages got updated shortly after the successful britney run (because they were prepared right before, just in case). Libraries:
    • [KiBi] libdrm: replace 2.4.23 with 2.4.24 (which was in experimental previously) unstable.
    • [KiBi] mesa: new stable release, 7.10.2 supersedes both 7.10 in unstable and 7.10.1 in experimental (see above) unstable.
    • [KiBi] pixman: new development snapshot, 0.21.6 comes from experimental and supersedes 0.21.4 unstable.
    Drivers:

10 April 2011

Cyril Brulebois: Getting replaced by scripts

As already blogged by Riku, getting replaced by script is really great! Until now, I ve had a crontab fetching my supporting-very-big-mails (up to 100MB or so) mailbox every few minutes, and looking into my =incoming-buildd/ maildir on a very regular fashion. With some simple mutt maildir hooks, replying to a Successful log would trigger extracting the changes file from there, setting some options, like PGP inline signing, and the mail would be ready to go back to the buildd. That part was just about being a GPG-signing monkey, so really not a funny part. Since we no longer have to worry about this boring and time-consuming task, I ve switched to a crontab firing up 4 times a day, and I try to deal with all incoming mails at once. Coupled with the new filters (e.g. on out-of-date packages on the buildd status page), I started using my time to file FTBFS bugs again, so that maintainers notice their packages fail to build without having to wait for a non-happening testing migration. After 10 days, the following mutt filter in =debian-bts/ lists 69 bugs:
~s "Bug#.*FTBFS" ~P ~d 01/04/2011-
(Subject contains Bug#.*FTBFS, mails from me, starting from 01/04/2011.) Figuring out whether that s due to another package s bug, an outdated chroot, a temporary glitch, etc. might take some time; that s why it s a bit hard to stay on top of things; and when the backlog grows up, motivation to go through this tedious task can be pretty low, especially when one sees repeated mistakes. I hope the amount of (possible) use cases for #620686 will decrease over time; instead, I d be very happy if maintainers could at least check what s mentioned in configure.ac/configure.in. Keeping an eye on its diff between upstream versions should be easy enough. ;)

9 April 2011

Cyril Brulebois: Debian XSF News #9

This is the ninth Debian XSF News issue. As can be seen below, I m not yet decided how to present various items. This time, I ll try to gather all updated packages since the previous issue, grouped by category, with a single line summary. Lengthy comments come after that list of updated packages.
  1. Here come the updated packages, with contributors/uploaders between square brackets (Timo = Timo Aaltonen, JVdG = Julien Viard de Galbert, Robert = Robert Hooker). Protocol:
    • [KiBi] x11proto-core: new upstream release, bringing Sinhala support experimental.
    Libraries:
    • [Timo,KiBi] libx11: new upstream release, fixing some hang issues unstable.
    • [KiBi] libxi: new upstream release unstable.
    • [KiBi] libxkbcommon: finally accepted by ftpmasters, needed for wayland experimental.
    Server:
    • [KiBi] xorg-server: stable release 1.9.5, unlikely to cause regressions from the previous release candidate; in other words: a good candidate for testing if the Linux kernel migrates some day unstable.
    • [KiBi] xorg-server: first release candidate for the first stable bugfix release in the 1.10 series, which finally builds experimental.
    Drivers: Others:
    • [KiBi] xorg: originally a few tweaks to make it possible to install X on Hurd unstable
    • [KiBi] xorg: but wkhtmltopdf failed on several buildds, so I disabled PDF generation, and completed the switch to asciidoc mentioned in DXN#8 unstable.
    • [KiBi] xorg-sgml-doctools: new upstream release, adds support for docbook external references unstable.
    • [Robert,KiBi] xutils-dev: new util-macros release, and a version lookup file unstable.
  2. Why am I carefully uploading video driver packages to experimental only? Because bad regressions happen, on a regular basis; so it seems quite nice to keep well-tested versions in unstable for now. Once the X stack has migrated to testing (which as explained in DXN#7 and DXN#8 is waiting for the Linux kernel to migrate), new versions in unstable are welcome, so that one can tell easily whether bugs with those versions are regressions from the versions available in testing. In the meanwhile, one can build packages from the git repositories, using the debian-unstable branch (which is the default).
  3. Why am I so rash then, uploading input drivers to unstable as they are released? First of all, our waiting for the kernel means we have no issues on the 10-day delay front. Second of all, input bugs are usually fixed very quickly upstream (you can go there and thank Peter Hutterer in particular). So staying very close to whatever upstream ships makes some sense.
  4. Why am I uploading drivers twice? Since it isn t specific to the current situation, but a general question when it comes to supporting two versions of the server in parallel, I decided to document that in an handling multiple server versions thanks to experimental page. The answer to this specific question is available in the note at the bottom of that page.
See you in a few days for a follow-up Debian XSF News issue.

5 April 2011

Cyril Brulebois: Running X from LXC

Mandatory warning: What follows is for testing only, and insecure (root all over the place, giving access to host devices from the container, etc.). Problem of the day Giving Linux containers a try Getting devices Example, with a Radeon card, KMS enabled, let s assume those devices are wanted:
crw-rw---- 1 root video 226, 0 Apr  5 02:34 /dev/dri/card0
crw-rw---- 1 root video  29, 0 Apr  5 02:34 /dev/fb0
crw------- 1 root root    4, 7 Apr  5 02:34 /dev/tty7
crw------- 1 root root    4, 8 Apr  5 02:34 /dev/tty8
Note the major, minor right between owner groups and dates, and edit the config file accordingly, adding those lines (watch the syntax, it doesn t like extra whitespaces):
lxc.cgroup.devices.allow = c 226:0 rwm
lxc.cgroup.devices.allow = c 29:0 rwm
lxc.cgroup.devices.allow = c 4:7 rwm
lxc.cgroup.devices.allow = c 4:8 rwm
Once the container restarted, create the devices:
cd /dev
mkdir -p dri
mknod -m 666 dri/card0 c 226 0
mknod -m 666 fb0       c 29 0
mknod -m 666 tty7      c 4 7
mknod -m 666 tty8      c 4 8
Getting serious Enjoy:
export DISPLAY=:0
awesome &
# this is not a benchmark:
glxgears &
# direct rendering:
glxinfo egrep '(direct renderer)'
which printed here:
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on ATI RS690

3 April 2011

Cyril Brulebois: Debian XSF News #8

This is the eighth Debian XSF News issue. For a change, I m going to use a numbered list, which should help telling people which item to look for when pointing to a given URL. Feel free to let me know if that seems like a nice idea or whether that hurts readability. Also, it was prepared several days ago already, so I m publishing it (with the needed bits of polishing it still needed) without mentioning what happened in the last few days (see you in the next DXN issue!).
  1. Let s start with a few common bugs reported over the past few weeks:
    • The server can crash due to some X Font Server (XFS) issue as reported upstream in FDO#31501 or in Debian as #616578. The easy fix is to get rid of FontPath in xorg.conf, or to remove the xfs package. It s deprecated anyway.
    • Xdm used to crash when started from init, but not afterwards (#617208). Not exactly fun to reproduce, but with the help of a VM, bisecting libxt to find the guilty commit was quite easy. After a quick upload with this commit reverted, a real fix was pushed upstream; a new upstream was released, packaged, and uploaded right after that.
    • We ve had several reports of flickering screens, which are actually due to upowerd s polling every 30 seconds: #613745.
    • Many bug reports were filed due to a regression on the kernel side for the 6.0.1 squeeze point release, leading to cursor issues with Intel graphics: #618665.
  2. Receiving several similar reports reminded me of the CurrentProblemsInUnstable page on the wiki, which is long unmaintained (and that s why I m not linking to it). I m not exactly sure what to do at this point, but I think having a similar page on http://pkg-xorg.alioth.debian.org/, linked from the how to report bugs page would make sense. Common issues as well as their solutions or workarounds for stable should probably go to the FAQ instead.
  3. As explained in DXN#7, we re waiting for the kernel to migrate to wheezy. The 2.6.38 upstream release was quickly pushed to unstable, which is great news, even if it s not really ready yet (since it s still failing to build on armel and mips).
  4. I ve been using markdown for our documentation, basically since it looked sufficient for our needs, and since I ve been using it to blog for years now, but it had some limitations. I ve been hearing a lot of nice things about asciidoc for a while (hi, Corsac!), so I gave it a quick shot. Being quite happy with it, I converted our documentation to asciidoc, which at the bare minimum buys us a nice CSS (at least nicer than the one I wrote ), and with automatic table of contents if we ask for it, which should help navigating to the appropriate place. A few drawbacks:
    • The syntax (or the parser s behaviour) changed a lot since lenny s version, so updating the online documentation broke badly. Thanks to the nice Alioth admins, the version from lenny-backports was quickly installed and the website should look fine.
    • The automatic table of contents is generated through JavaScript, which doesn t play nicely with wkhtmltopdf (WebKit-based HTML to PDF converter), since the table of contents gets pixelated in the generated PDF documents. We could use a2x to generate documents through the DocBook way, but that means dealing with XSL stylesheets as far as I can tell; that looks time-consuming and a rather low-priority task. But of course, contributions are welcome.
  5. When I fixed missing XSecurity (#599657) for squeeze, I didn t notice the 1.9 packages were forked right before that, so were affected too. I fixed it in sid since then (and in git for experimental). I noticed that when Ian reported a crash with large timeouts in xauth calls, which I couldn t reproduce since untrusted cookies without XSecurity don t trigger this issue. I reported that upstream as FDO#35066, which got marked as a duplicate of (currently restricted) FDO#27134. My patch is currently still waiting for a review.
  6. Let s mention upcoming updates, prepared in git, but not uploaded yet:
    • mesa 7.10.1, prepared by Chris (RAOF); will probably be uploaded to experimental, unless 7.10 migrates to testing first, in which case that update will target unstable.
    • Intel driver: Lintian s been complaining about the .so symlinks for a while, and I finally gave it a quick look. It seems one is supposed to put e.g. libI810XvMC.so.1 in /etc/X11/XvMCConfig to use that library, so the symlinks are indeed not needed at all, and I removed them.
    • Tias Guns and Timo Aaltonen introduced xinput-calibrator in a git repository; that s a generic touchscreen calibration tool.
  7. Here come the updated packages, with uploader between square brackets (JVdG = Julien Viard de Galbert, Sean = Sean Finney). For the next issue, I ll try to link to the relevant entries in the Package Tracking System.
    • [KiBi] libxt: to unstable, as mentioned above, with a hot fix, then with a real fix.
    • [KiBi] synaptics input driver: to unstable and experimental, fixing the FTBFS on GNU/kFreeBSD.
    • [KiBi] xterm: new upstream, to unstable.
    • [KiBi] libdrm: new upstream, to experimental. A few patches to hide private symbols were sent upstream, but I ve seen no reactions yet (and that apparently happened in the past already).
    • [KiBi] xorg-server 1.9.5rc1 then 1.9.5, to unstable.
    • [KiBi] xutils-dev to unstable: the bootstrap issue goes away, thanks to Steve s report.
    • [KiBi] libxp to unstable, nothing fancy, that s libxp
    • [KiBi] keyboard input driver: mostly documentation update, to unstable and experimental.
    • [KiBi] mouse input driver: fixes BSD issues, to unstable and experimental.
    • [KiBi] intel video driver: to experimental, but the debian-unstable branch can be used to build the driver against unstable s server.
    • [KiBi] xfixes: protocol to unstable, and library to experimental (just in case); this brings support for pointer barriers.
    • [JVdG] openchrome video driver: Julien introduced a debugging package, and got rid of the (old!) via transitional package. He also performed his first upload as a Debian Maintainer. Yay!
    • [KiBi] siliconmotion video driver: to unstable.
    • [KiBi] pixman: new upstream release candidate, to experimental
    • [Sean] last but not least: many compiz packages to experimental.

4 March 2011

Cyril Brulebois: Debian XSF News #7

Time for a seventh Debian XSF News issue!

3 March 2011

Rapha&#235;l Hertzog: People behind Debian: Christian Perrier, translation coordinator

Christian is a figure of Debian, not only because of the tremendous coordination work that he does within the translation project, but also because he s very involved at the social level. He s probably in the top 5 of the persons who attended most often the Debian conference. Christian is a friend (thanks for hosting me so many times when I come to Paris for Debian related events) and I m glad that he accepted to be interviewed. He likes to speak and that shows in the length of his answers :-) but you ll be traveling the world while reading him. My questions are in bold, the rest is by Christian. Who are you? I am a French citizen (which is easy to guess unless you correct my usual mistakes in what follows). I m immensely proud of being married for nearly 26 years with Elizabeth (who deserves a statue from Debian for being so patient with my passion and my dedication to the project). I m also the proud father of 3 wonderful kids , aged 19 to 23. I work as team manager in the Networks and Computers Division of Onera the French Aerospace lab , a public research institute about Aeronautics, Space and Defense. My team provides computer management services for research divisions of Onera, with a specific focus put on individual computing. I entered the world of free software as one of the very first users of Linux in France. Back in the early 1990 s, I happened (though the BBS users communities) to be a friend of several early adopters of Linux and/or BSD386/FreeBSD/NetBSD in France. More specifically, I discovered Linux thanks with my friend Ren Cougnenc (all my free software talks are dedicated to Ren , who passed away in 1996). You re not a programmer, not even a packager. How did you come to Debian? I m definitely not a programmer and I never studied computing (I graduated in Materials Science and worked in that area for a few years after my PhD). However, my daily work always involved computing (I redesigned the creep testing laboratory and its acquisition system all by myself during my thesis research work). An my hobbies often involved playing with home computers, always trying to learn about something new. So, first learning about a new operating system then trying to figure out how to become involved in its development was quite a logical choice. Debian is my distro of choice since it exists. I used Slackware on work machines for a while, but my home server, kheops, first ran Debian 1.1 when I stopped running a BBS on an MS-DOS machine to host a news server. That was back in October 1996. I then happened to be a user, and more specifically a user of genealogy software, also participating very actively in Usenet from this home computer and server, that was running this Debian thing. So, progressively, I joined mailing lists and, being a passionate person, I tried to figure out how I could bring my own little contribution to all this. This is why I became a packager (yes, I am one!) by taking over the geneweb package, which I was using to publish my genealogy research. I applied as DD in January 2001, then got my account in July 2001. My first upload to the Debian archive occurred on August 22nd 2001: that was of course geneweb, which I still maintain. Quite quickly, I became involved in the work on French localization. I have always been a strong supporter of localized software (I even translated a few BBS software back in the early 90 s) as one of the way to bring the power and richness of free software to more users. Localization work lead me to work on the early version of Debian Installer, during those 2003-2005 years where the development of D-I was an incredibly motivating and challenging task, lead by Joey Hess and his inspiring ideas. From user to contributor to leader, I suddenly discovered, around 2004, that I became the coordinator of D-I i18n (internationalization) without even noticing :-) You re the main translation coordinator in Debian. What plans and goals have you set for Debian Wheezy? As always: paint the world in red. Indeed, this is my goal for years. I would like our favorite distro to be able to be used by anyone in the world, whether she speaks English, Northern Sami, Wolof, Uyghur or Secwepemcts n. As a matter of symbol, I use the installer for this. My stance is that one should be able to even install Debian in one s own language. So, for about 7 years, I use D-I as a way to attract new localization contributors. This progress is represented on this page where the world is gradually painted in red as long as the installer supports more languages release after release. The map above tries to illustrate this by painting in red countries when the most spoken language in the country is supported in Debian Installer. However, that map does not give enough reward to many great efforts made to support very different kind of languages. Not only various national languages, but also very different ones: all regional languages of Spain, many of the most spoken languages in India, minority languages such as Uyghur for which an effort is starting, Northern Sami because it is taught in a few schools in Norway, etc., etc. Still, the map gives a good idea of what I would like to see better supported: languages from Africa, several languages in Central Asia. And, as a very very personal goal, I m eagerly waiting for support of Tibetan in Debian Installer, the same way we support its sister language, Dzongkha from Bhutan. For this to happen, we have to make contribution to localization as easy as possible. The very distributed nature of Debian development makes this a challenge, as material to translate (D-I components, debconf screens, native packages, packages descriptions, website, documentation) is very widely spread. A goal, for years, is to set a centralized place where translators could work easily without even knowing about SVN/GIT/BZR or having to report bugs to send their work. The point, however, would be to have this without making compromises on translation quality. So, with peer review, use of thesaurus and translation memory and all such techniques. Tools for this exist: we, for instance, worked with the developers of Pootle to help making it able to cope with the huge amount of material in Debian (think about packages descriptions translations). However, as of now, the glue between such tools and the raw material (that often lies in packages) didn t come. So, currently, translation work in Debian requires a great knowledge of how things are organized, where is the material, how it can be possible to make contribution reach packages, etc. And, as I m technically unable to fulfill the goal of building the infrastructure, I m fulfilling that role of spreading out the knowledge. This is how I can define my coordinator role. Ubuntu uses a web-based tool to make it easy to contribute translations directly in Launchpad. At some point you asked Canonical to make it free software. Launchpad has been freed in the mean time. Have you (re)considered using it? Why not? After all, it more or less fills in the needs I just described. I still don t really figure out how we could have all Debian material gathered in Rosetta/Launchpad .and also how Debian packagers could easily get localized material back from the framework without changing their development processes. I have always tried to stay neutral wrt Ubuntu. As many people now in Debian, I feel like we have reached a good way to achieve our mutual development. When it comes at localization work, the early days where the everything in Rosetta and translates who wants stanza did a lot of harm to several upstream localization projects is, I think, way over. Many people who currently contribute to D-I localization were indeed sent to me by Ubuntu contributors .and by localizing D-I, apt, debconf, package descriptions, etc., they re doing translation work for Ubuntu as well as for Debian. Let s say I m a Debian user and I want to help translate Debian in my language. I can spend 1 hour per week on this activity. What should I do to start? Several language teams use Debian mailing lists to coordinate their work. If you re lucky enough to be a speaker of one of these languages, try joining debian-l10n-<yourlanguage> and follow what s happening there. Don t try to immediately jump in some translation work. First, participate to peer reviews: comment on others translations. Learn about the team s processes, jargon and habits. Then, progressively, start working on a few translations: you may want to start with translations of debconf templates: they are short, often easy to do. That s perfect if you have few time. If no language team exists for your language, try joining debian-i18n and ask about existing effort for your language. I may be able to point you to individuals working on Debian translations (very often along with other free software translation efforts). If I am not, then you have just been named coordinator for your language :-) I may even ask you if you want to work on translating the Debian Installer. What s the biggest problem of Debian? We have no problems, we only have solutions :-) We are maybe facing a growth problem for a few years. Despite the increased welcoming aspects of our processes (Debian Maintainers), Debian is having hard times in growing. The overall number of active contributors is probably stagnating for quite a while. I m still amazed, however, to see how we can cope with that and still be able to release over the years. So, after all, this is maybe not a problem :-) Many people would point communication problems here. I don t. I think that communication inside the Debian project is working fairly well now. Our famous flame wars do of course still happen from time to time, but what large free software project doesn t have flame wars? In many areas, we indeed improved communication very significantly. I want to take as an example the way the release of squeeze has been managed. I think that the release team did, even more this time, a very significant and visible effort to communicate with the entire project. And the release of squeeze has been a great success in that matter. So, there s nearly nothing that frustrates me in Debian. Even when a random developer breaks my beloved 100% completeness of French translations, I m not frustrated for more than 2 minutes. You re known in the Debian community as the organizer of the Cheese & Wine Party during DebConf. Can you tell us what this is about? This is an interesting story about how things build themselves in Debian. It all started in July 2005, before DebConf 5 in Helsinki. Denis Barbier, Nicolas Fran ois and myself agreed to bring at Debconf a few pieces of French cheese as well as 1 or 2 bottles of French wine and share them with some friends. Thus, we settled an informal meeting in the French room where we invited some fellows: from memory, Benjamin Mako Hill, Hannah Wallach, Matt Zimmermann and Moray Allan. All of us fond of smelly cheese, great wine plus some extra p t home-made by Denis in Toulouse. It finally happened that, by word of mouth, a few dozens of other people slowly joined in that French room and turned the whole thing into an improvized party that more or less lasted for the entire night. The tradition was later firmly settled in 2006, first in Debconf 6 in Mexico where I challenged the French DDs to bring as many great cheese as possible, then during the Debian i18n meeting in Extremadura (Sept 2006) where we reached the highest amount of cheese per participant ever. I think that the Creofonte building in Casar de C ceres hasn t fully recovered from it and is still smelling cheese 5 years after. This party later became a real tradition for DebConf, growing over and over each year. I see it as a wonderful way to illustrate the diversity we have in Debian, as well as the mutual enrichment we always felt during DebConfs. My only regret about it is that it became so big over the years that organizing it is always a challenge and I more and more feel pressure to make it successful. However, over the years, I always found incredible help by DebConf participants (including my own son, last year a moment of sharing which we will both remember for years, i think). And, really, in 2010, standing up on a chair, shouting (because the microphone wasn t working) to thank everybody, was the most emotional moment I had at Debconf 10. Is there someone in Debian that you admire for their contributions? So many people. So, just like it happens in many awards ceremonies, I will be very verbose to thank people, sorry in advance for this. The name that comes first is Joey Hess. Joey is someone who has a unique way to perceive what improvements are good for Debian and a very precise and meticulous way to design these improvements. Think about debconf. It is designed for so long now and still reaching its very specific goal. So well designed that it is the entire basis for Joey s other achievement: designing D-I. Moreover, I not only admire Joey for his technical work, but also for his interaction with others. He is not he loudest person around, he doesn t have to .just giving his point in discussion and, guess what? Most of the time, he s right. Someone I would like to name here, also, is Colin Watson. Colin is also someone I worked with for years (the D-I effect, again ) and, here again, the very clever way he works on technical improvements as well as his very friendly way to interact with others just make it. And, how about you, Rapha l? :-) I m really admirative of the way you work on promoting technical work on Debian. Your natural ability to explain things (as good in English as it is in French) and your motivation to share your knowledge are a great benefit for the project. Not to mention the technical achievements you made with Guillem on dpkg of course! Another person I d like to name here is Steve Langasek. We both maintain samba packages for years and collaboration with him has always been a pleasure. Just like Colin, Steve is IMHO a model to follow when it comes at people who work for Canonical while continuing their involvment in Debian. And, indeed, Steve is so patient with my mistakes and stupid questions in samba packaging that he deserves a statue. We re now reaching the end of the year where Stefano Zacchiroli was the Debian Project Leader. And, no offense intended to people who were DPL before him (all of them being people I consider to be friends of mine), I think he did the best term ever. Zack is wonderful in sharing his enthusiasm about Debian and has a unique way to do it. Up to the very end of his term, he has always been working on various aspects of the project and my only hope is that he ll run again (however, I would very well understand that he wants to go back to his hacking activities!). Hat off, Zack!I again have several other people to name in this Bubulle hall of Fame : Don Armstrong, for his constant work on improving Debian BTS, Margarita Manterola as one of the best successes of Debian Women (and the most geeky honeymoon ever), Denis Barbier and Nicolas Fran ois because i18n need really skilled people, Cyril Brulebois and Julien Cristau who kept X.org packaging alive in lenny and squeeze, Otavio Salvador who never gave up on D-I even when we were so few to care about it. I would like to make a special mention for Frans Pop. His loss in 2010 has been a shock for many of us, and particularly me. Frans and I had a similar history in Debian, both mostly working on so-called non technical duties. Frans has been the best release manager for D-I (no offense intended, at all, to Joey or Otavio .I know that both of them share this feeling with me). His very high involvment in his work and the very meticulous way he was doing it lead to great achievements in the installer. The Installation Guide work was also a model and indeed a great example of non technical work that requires as many skills as more classical technical work. So, and even though he was sometimes so picky and, I have to admit, annoying, that explains why I m still feeling sad and, in some way, guilty about Frans loss. One of my goals for wheezy is indeed to complete some things Frans left unachieved. I just found one in bug #564441: I will make this work reach the archive, benefit our users and I know that Frans would have liked that.
Thank you to Christian for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

7 comments Liked this article? Click here. My blog is Flattr-enabled.

21 February 2011

Cyril Brulebois: Debian XSF News #6

Enough news to release another Debian XSF News issue, after less than a week. Enough writing for now, I m getting new mails in xorg-announce@.

17 February 2011

Cyril Brulebois: Debian XSF News #5

Time for a fifth Debian XSF News issue!

8 February 2011

Cyril Brulebois: Debian XSF News #4

Here comes the forth Debian XSF News issue! I usually try to keep the items sorted chronologically (but grouped by topic when possible), so if you re wondering about the current status of X in unstable, make sure you read the last entry.

1 February 2011

Cyril Brulebois: Debian XSF News #3

Time for a third Debian XSF News issue! Debian XSF News #3 It s been a year On a personal note, it s been a year to the day since I first looked into X. After having hacked on the Debian Installer to make it use X.Org instead of DirectFB, I did some heavy bug triaging, resulting in a drop in the xorg-server bug count in March. The same happened past week as written above, resulting in a second drop. In the meanwhile, the bug count remained more or less stable, since we try to reply quickly to new bugs, and since Julien Viard de Galbert does bug triaging on a weekly basis: BTS graph for xorg-server One might ask: what does maintaining X mean?

31 January 2011

Cyril Brulebois: Oldest bug closed ever

A few days ago, I closed two bugs in the #17xxx range and I found that pretty cool already. But a few hours ago, I closed #6734, which is the oldest bug I ever closed! It took more than 14 years for somebody to reply, oops Next one to take care of, #2297. Apparently, it s so old that the initial bug report was lost at some point.

21 January 2011

Cyril Brulebois: Debian XSF News #2

Time for a second Debian XSF News issue! I ll skip stuff related to the new katamari since I wrote about that already.

17 January 2011

Julien Viard de Galbert: Triaging bugs is not that hard !

There is a big thread on -devel that started about Forwarding bugs upstream, the idea is that it should be the maintainer s job. While it s true in general, some understaffed teams are so flooded by bugs that they just can t do it.
I ve seen more than once the X Strike Force asking a user to report upstream (pointing to the relevant BTS) and come back with the tracking URL to be attached to the bug. This was mostly for driver issue if I remember well.
And most users did it, so thanks! Then the thread evolved in lots of directions, I m not following all of it, but there was the question of the bug triaging and as I m doing it for the X packages, I want to share about my experience here. The available triaging docs The debian wiki already have a general Bug Triage page.
The thread pointed to the KDE Bug triaging page.
The X Strike Force has some pages, one on the wiki and a new one more specific to bug triaging on the alioth project s doc.
And when it comes to closing bugs with version information, there is a good read on the wiki: Bugs Version Tracking.
Finally don t hesitate to reopen the BTS documentation whenever you need to write to control@b.d.o ! Now if all those docs don t help you, then try to improve the docs as a first step ! ;) Talk with the maintainer(s) Well I did met Julien Cristau and Cyril Brulebois in person during mini-DebConf Paris/2010 that certainly helped. But we exchanged several mails, or met on IRC channel #debian-x.
But the triaging rules of the X Strike Force (linked above) were pretty clear anyway. My current process This process has evolved over time with the response of several contributors either to help or to fix to my mistakes, thanks!
  1. List bug from UDD: XSF unstable bugs sorted by date.
  2. Pick an old bug (once you answer and UDD runs, the bug moves down the list, so there are always old bugs on the top).
  3. Read the report, don t be afraid by the subject, it might be unrelated, the bug might be merged with other bugs, then reading the other bugs can help.
  4. If relevant try to reproduce it. (most bugs in X are hardware related or specific to one setup, so it s not that often that I have something to test).
  5. Decide what to do, most of the time, I will ping the submitter.
  6. I m a mutt user, and to my help the bts command as a way to open the bug mbox in mutt, that makes it really easy to answer the bug.
    So I launch bts -m show $n where $n is the bug number, and I can then answer the bug from mutt.
    The triaging procedure suggest to ping -submitter, but using mutt it s easier to just reply and add a -quiet to the bug number (this avoid spamming the debian-x with all my pings).
  7. In the message, always try to be kind and helpful, most of the time ask to test newer versions.
  8. Keep track of the pinged bugs, well I do it for my blog but it will be useful anyway, see below.
  9. When the submitter answers, just react accordingly, if the bug can be closed, then close it ! ;)
  10. If after some time, the bug are still not answered, consider closing them (I haven t started that yet, but this will probably get the bug number down faster:) ).
Note: Sometime I don t send the bug to -quiet so that other debian-x subscriber can have a look at the bug. They then can give me advices, or close the bug directly with a stronger reason than any I could have found. ;) To submitters, please keep the bug CCed when you answer, thanks. For the skeptics Yes as a newbie I did some mistakes, but I was always corrected in a nice way, with explanations. Also I try to have a conservative approach, I don t close bugs if I m not sure, I ask if I can close them, so it might take longer, but in the end the effect is the same for the bug, but not the same to the submitter ! ;) Also this work might look boring, but it s actually rewarding, most of the answers I received included a cheerful message thanking me for following up on the bug. Not to mention all I ve learned on Xorg. Conclusion As long as I have time for it, I ll continue to triage bugs and I d love to see others coming to help me on X or probably better go and help some other teams that also need help, and flood the planet with bug triaging reports ! ;) Get involved !

13 January 2011

Cyril Brulebois: X11R7.6: Katamari summary

X11R7.6 got released on the 20th of December 2010. There were several status updates about XServer 1.9 in experimental on this blog previously, but here s a more thorough review of this katamari. Terminology: that s how upstream calls a badged annual rollup release. In other words, the server, drivers, client libraries, protocols, fonts, and basic applications are all individually released, and a rollup of all those is released from time to time, with a version for all of those components. The term comes from a series of video games. (Explanations taken from a message by Alan Coopersmith.) Katamaris are released with a consolidated changelog, where all components and versions are listed. There s also a git shortlog available for each component, pointing back to freedesktop s git web interface for each and every commit. I modified the table of versions to get the following table, dropping the X11R7.5 column, and adding a distribution one, so as to mention where each component for X11R7.6 can be found. It boils down mostly to: So there s the summary:
Type Component Version Distribution
xserver 1.9.3 experimental
app bdftopcf 1.0.3 unstable
app iceauth 1.0.4 experimental
app luit 1.1.0 experimental
app mkfontdir 1.0.6 unstable
app mkfontscale 1.0.8 unstable
app sessreg 1.0.6 unstable
app setxkbmap 1.2.0 experimental
app smproxy 1.0.4 experimental
app x11perf 1.5.2 experimental
app xauth 1.0.5 unstable
app xbacklight 1.1.2 will be dropped
app xcmsdb 1.0.3 experimental
app xcursorgen 1.0.4 experimental
app xdpyinfo 1.2.0 experimental
app xdriinfo 1.0.4 experimental
app xev 1.1.0 experimental
app xgamma 1.0.4 experimental
app xhost 1.0.4 experimental
app xinput 1.5.3 unstable
app xkbcomp 1.2.0 experimental
app xkbevd 1.1.2 experimental
app xkbutils 1.0.3 experimental
app xkill 1.0.3 experimental
app xlsatoms 1.1.0 unstable
app xlsclients 1.1.1 experimental
app xmodmap 1.0.5 experimental
app xpr 1.0.3 will be dropped
app xprop 1.2.0 experimental
app xrandr 1.3.4 experimental
app xrdb 1.0.7 experimental
app xrefresh 1.0.4 experimental
app xset 1.2.1 experimental
app xsetroot 1.1.0 experimental
app xvinfo 1.1.1 experimental
app xwd 1.0.4 experimental
app xwininfo 1.1.1 experimental
app xwud 1.0.3 experimental
data bitmaps 1.1.1 unstable
data cursors 1.0.3 unstable
doc xorg-docs 1.6 unstable
doc xorg-sgml-doctools 1.6 unstable
driver xf86-input-acecad 1.4.0 experimental
driver xf86-input-aiptek 1.3.1 experimental
driver xf86-input-evdev 2.5.0 experimental
driver xf86-input-joystick 1.5.0 experimental
driver xf86-input-keyboard 1.5.0 experimental
driver xf86-input-mouse 1.6.0 experimental
driver xf86-input-synaptics 1.3.0 experimental
driver xf86-input-vmmouse 12.6.10 experimental
driver xf86-input-void 1.3.1 experimental
driver xf86-video-apm 1.2.3 experimental
driver xf86-video-ark 0.7.3 experimental
driver xf86-video-ast 0.91.10 dropped
driver xf86-video-ati 6.13.2 experimental
driver xf86-video-chips 1.2.3 experimental
driver xf86-video-cirrus 1.3.2 experimental
driver xf86-video-dummy 0.3.4 experimental
driver xf86-video-fbdev 0.4.2 experimental
driver xf86-video-geode 2.11.10 todo: needs upload
driver xf86-video-glide 1.1.0 experimental
driver xf86-video-glint 1.2.5 experimental
driver xf86-video-i128 1.3.4 experimental
driver xf86-video-i740 1.3.2 experimental
driver xf86-video-intel 2.13.0 experimental
driver xf86-video-mach64 6.8.2 experimental
driver xf86-video-mga 1.4.13 experimental
driver xf86-video-neomagic 1.2.5 experimental
driver xf86-video-newport 0.2.3 todo: needs upload
driver xf86-video-nv 2.1.18 will be dropped
driver xf86-video-r128 6.8.1 experimental
driver xf86-video-rendition 4.2.4 experimental
driver xf86-video-s3 0.6.3 experimental
driver xf86-video-s3virge 1.10.4 experimental
driver xf86-video-savage 2.3.1 experimental
driver xf86-video-siliconmotion 1.7.4 experimental
driver xf86-video-sis 0.10.3 experimental
driver xf86-video-sisusb 0.9.4 experimental
driver xf86-video-suncg14 1.1.1 experimental
driver xf86-video-suncg3 1.1.1 experimental
driver xf86-video-suncg6 1.1.1 experimental
driver xf86-video-sunffb 1.2.1 experimental
driver xf86-video-sunleo 1.2.0 experimental
driver xf86-video-suntcx 1.1.1 experimental
driver xf86-video-tdfx 1.4.3 experimental
driver xf86-video-tga 1.2.1 experimental
driver xf86-video-trident 1.3.4 experimental
driver xf86-video-tseng 1.2.4 experimental
driver xf86-video-v4l 0.2.0 dropped
driver xf86-video-vesa 2.3.0 experimental
driver xf86-video-vmware 11.0.3 experimental
driver xf86-video-voodoo 1.2.4 experimental
driver xf86-video-wsfb 0.3.0 dropped
driver xf86-video-xgi 1.6.0 dropped
driver xf86-video-xgixp 1.8.0 dropped
font fonts skipped
lib libAppleWM 1.4.0 not for us
lib libFS 1.0.3 unstable
lib libICE 1.0.7 unstable
lib libSM 1.2.0 unstable
lib libWindowsWM 1.0.1 not for us
lib libX11 1.4.0 experimental
lib libXScrnSaver 1.2.1 unstable
lib libXau 1.0.6 unstable
lib libXaw 1.0.8 unstable
lib libXcomposite 0.4.3 unstable
lib libXcursor 1.1.11 unstable
lib libXdamage 1.1.3 unstable
lib libXdmcp 1.1.0 unstable
lib libXext 1.2.0 experimental
lib libXfixes 4.0.5 unstable
lib libXfont 1.4.3 experimental
lib libXft 2.2.0 experimental
lib libXi 1.4.0 experimental
lib libXinerama 1.1.1 unstable
lib libXmu 1.1.0 unstable
lib libXpm 3.5.9 unstable
lib libXrandr 1.3.1 unstable
lib libXrender 0.9.6 unstable
lib libXRes 1.0.5 unstable
lib libXt 1.0.9 experimental
lib libXtst 1.2.0 unstable
lib libXv 1.0.6 unstable
lib libXvMC 1.0.6 unstable
lib libXxf86dga 1.1.2 unstable
lib libXxf86vm 1.1.1 unstable
lib libdmx 1.1.1 unstable
lib libfontenc 1.1.0 unstable
lib libpciaccess 0.12.0 unstable
lib libxkbfile 1.0.7 unstable
lib libxtrans 1.2.6 unstable
proto applewmproto 1.4.1 not for us
proto bigreqsproto 1.1.1 unstable
proto compositeproto 0.4.2 unstable
proto damageproto 1.2.1 unstable
proto dmxproto 2.3 unstable
proto dri2proto 2.3 unstable
proto fixesproto 4.1.2 unstable
proto fontsproto 2.1.1 unstable
proto glproto 1.4.12 unstable
proto inputproto 2.0.1 unstable
proto kbproto 1.0.5 unstable
proto randrproto 1.3.2 unstable
proto recordproto 1.14.1 unstable
proto renderproto 0.11.1 unstable
proto resourceproto 1.1.1 unstable
proto scrnsaverproto 1.2.1 unstable
proto videoproto 2.3.1 unstable
proto windowswmproto 1.0.4 not for us
proto xcmiscproto 1.2.1 unstable
proto xextproto 7.1.2 unstable
proto xf86bigfontproto 1.2.0 unstable
proto xf86dgaproto 2.1 unstable
proto xf86driproto 2.1.0 unstable
proto xf86vidmodeproto 2.3 unstable
proto xineramaproto 1.2 unstable
proto x11proto 7.0.20 unstable
util makedepend 1.0.3 unstable
util macros 1.11.0 unstable
xcb pthread-stubs 0.3 unstable
xcb libxcb 1.7 experimental
xcb proto 1.6 unstable

Next.

Previous.